1. Field of the Invention
The present invention relates to a method for controlling a network configured by such network nodes as LAN switches, etc., as well as Web and other servers and SAN, NAS, and other storage devices.
2. Description of the Related Art
A conventional network policy controlling method has been discussed, for example, in the IETF (Internet Engineering Task Force) and the following document describes the method briefly “A policy server under production” pp.144 to 151, June, 1999, Nikkei Internet Technology.
In a network system that does not control policies, control of the QoS management function (service quality management function), the security management function, etc. is set individually in each network device. In a network system that controls policies, however, it is possible to specify the policies throughout the network. Thus, the user is required to input only a small amount of setting information. In addition, the time can be subdivided to change policies and policies can be changed dynamically in response to a request from an application program. Thus, the network comes to be controlled more efficiently, which is usually not realized by any operator.
A policy is usually described as a list of rules referred to as policy rules. Policy rules are condition-action type rules. In other words, a policy rule describes an action to be performed when its condition is satisfied. One policy can include any condition and action. However, it is also possible to limit a policy rule so that one policy includes only a policy rule having a specific format and item to simplify policy processings and user interfaces. The policy server PolicyXpert (TM), which is a joint product of Hewlett-Packard Company and Hitachi, Ltd., is configured so that one policy includes only a specific type policy rule by employing a concept for action patterns that can be specified in policy rules. Consequently, each policy has a pattern (policy pattern) corresponding to an action pattern to be included therein. The format and meaning of the PolicyXpert policy are described in the following document.
HP OpenView PolicyXpert User's Guide, J1360-90010 (http://ovweb.external.hb.com/ovnsmdps/pdf/j1360-90010.pdf), Hewlett-Packard, 2001.
The formats and meanings of policies are now standardized as “policy information models” in the IETF (Internet Engineering Task Force). The core information model is described in the following documents:
Moore, B., Ellesson, E., Strassner, J., and Westerinen, A., “Policy Core Information Model Version 1 Specification”, RFC 3060, (http://www.ietf.org/rfc/rfc3060.txt), IETF, February 2001.
Moore, B., Rafalow, L., Ramberg, Y., Smirk, Y., Strassner, J., Westerinen, A., Chadha, R., Brunner, M., Cohen, R., “Policy Core Information Model Extensions”, draft-ietf-policy-pcim-ext-05.txt (http://www.ietf.org/internet-drafts/draft-ietf-policy-pcim-ext-05.txt), Internet Draft, IETF, 2001
Although there are a plurality of protocols used to download policies to devices, the COPS (Common Open Policy Service) protocol is usually used. The COPS protocol is proposed by the IETF in the following documents:
The COPS (Common Open Policy Service) Protocol edited by D. Durham, RFC 2748, (http://www.ietf.org/rfc/rfc2748.txt), IETF, 2000; and
COPS Usage for Policy Provisioning (COPS-PR) written by F. Reichmeyer et al, RFC 3084, (http://www.ietf.org/rfc/rfc3084.txt), IETF, 2001.
A PIB (Policy Information Base) is also proposed to describe policies to be downloaded. The following document describes one of the examples.
Quality of Service Policy Information Base, draft-mfile-cops-pib-05.txt written by M. Fine et. al., (http://www.ietf.org/internet-drafts/draft-mfine-cops-pib-05.txt), Internet Draft, IETF, 2001.
A conventional technique for assuring the QoS (Quality of Service) in the Internet is the Differentiated Services Technique (“the DiffServ technique”). The DiffServ technique is described in the following documents:
An Architecture for Differentiated Services written by S. Blake et al, RFC 2475, (http://www.ietf.org/rfc/rfc2475.txt), IETF, 1998; and
A Two-bit Differentiated Services Architecture for the Internet written by K. Nichols et al, RFC 2638, (http://www.ietf.org/rfc/rfc2638.txt), IETF, 1999.
The DiffServ technique, when a series of packets are communicated from the first network application to a second network application through a network, those packets are considered as one “flow” or a series of packets flow. The DiffServ technique can determine whether or not a flow includes an IP packet by identifying the IP addresses at both start and end of the IP packet, the protocol type, and the port when the protocol is TCP or UDP.
In a path from the first network application to the second network application, at first, a network inlet edge router is formed, then no router, otherwise one or more core routers are formed, and finally, a network outlet edge router is formed. The DiffServ technique marks a plurality of flows with a specific value set in the DS field (Differentiated Services field) of each packet at the inlet edge router so as to handle all the packets having the value as one flow (aggregated flow) collectively in the succeeding processings. The value set in the DS field is referred to as a DSCP (Differentiated Services CodePoint). Creating such an aggregated packet flow makes it possible for the core router to determine only the DSCP to control the QoS conditions as a band width, packet transfer priority, etc. of each aggregated flow. The use of the DiffServ will thus make it possible to aggregate a flow, determine the flow only with the DSCP, and reduce the load of the core router that controls the QoS conditions.
The use of the DiffServ technique also makes it possible to assure the end-to-end communication quality even in a network configuration comprising a plurality of networks such as a LAN through the Ethernet or a WAN through an IP net, etc. This is because flow identification and priority controlling can be realized similarly in those networks.
While networks, servers that are actually work stations, personal computers, and disk storage devices have been developed independently of each another, a concept that those items should be managed integrally is now being promoted. For example, when a LAN, a WAN between offices, a Web server, a database server, and storage devices used for them are controlled integrally with use of policies in a corporation, those items can be employed more strategically.
In such an environment, it is required firstly to enable a usable latest technique to be controlled with use of policies immediately after introduction and those policies to be designed/used in accordance with needs. There is no time to wait for standardized policies and QoS conditions to be issued the IETF as described above. In the conventional policy systems, the users have only been allowed to handle policies having specific functions pre-installed in policy servers and policy agents.
Furthermore, the environment as described above often includes the second problem that policies have to be distributed to network devices, servers, and storage devices so that those devices can be managed integrally. The conventional policy systems have enabled the users to combine only predetermined types of device interfaces for use such as, for example, a combination of a Simple Network Management Protocol (SNMP) and a (Management Information Base)(MIB), a combination of a COPS-PR and a PIB, and a specific command-line interface (CLI) and a specific API, are only allowed for use; devices that do not have any of the interfaces cannot be used. Consequently, those systems have been limited and can control only some of the devices even in a comparatively standardized network. Controlling of those devices with policies has hardly been possible in servers and storage devices that have not yet been standardized.